Method for storage and transport of an electronic certificate

ABSTRACT

The aim of this invention is to assure the portability of an electronic certificate and the security of the private key which are part of the certificate X509. In fact, it is important that this certificate is not used for purposes uncontrolled by the holder, such as identity usurpation, the authorization of non-desired transactions or the reproduction of transactions (replay). This aim is reached by a storage and transporting method for an electronic certificate, said certificate having an authority section for the issuing authority, a holder section for the holder of the certificate and a signature section determined by the issuing authority, characterized in that all or part of the holder section is contained in a removable security module and that at least the authority section is contained in a host computer.

This invention concerns a storage and transport method for a X.509 typecertificate.

The electronic certificate, like for example type X.509, is a collectionof information for everything concerning the identification of a holderelectronically. This certificate is given by an accredited authoritythat undertakes to identity the holder possessing such a certificate.

This is why, according to the level of undertaking of the authoritygiving the certificate, they can demand that the holder providesguarantees of his identity, for example that a notary confirms hisidentity.

This certificate is schematically composed of a part corresponding tothe issuing authority and a part corresponding to the holder of thecertificate, which is called “explicit”.

The part corresponding to the authority can be identical for all thecertificates given by this authority. This part is called “implicit”.

To render these two parts inseparable, a certificate comprises asignature written on these two parts by means of the authority's privatekey.

When such a certificate is received from a storage server, the signatureis verified thanks to the public key of the issuing authority. This keycan be found in the certificate originating from the issuing authority.As indicated above, the signature allows one to verify the authenticityof the certificate's contents. These certificates are generally storedin a storage unit of a computer, as well as the root certificate, whichis the certificate of the issuing authority.

There is thus an interest in disposing of a certificate stored on aremovable support allowing the authentication module role to be used inthis way.

For this reason, a simple diskette is sufficient to transport thecertificate, support used at times to transmit such a certificate to auser.

Nevertheless this principle does not offer sufficient security for thestorage of the private key, which is also necessary for on linetransaction operations.

This is why the aim of this invention is to assure the portability of anelectronic certificate and the security of the private key.

In fact, it is important that this certificate is not used for purposesuncontrolled by the holder, such as identity usurpation, theauthorization of non-desired transactions or the reproduction oftransactions (replay).

This aim is reached by a storage and transporting method for anelectronic certificate, said certificate having an authority section forthe issuing authority, a holder section for the holder of thecertificate and a signature section determined by the issuing authority,characterized in that all or part of the holder section is contained ina removable security module and that at least the authority section iscontained in a host computer.

This method also has the advantage of reducing the quantity ofinformation stored in the security module. This module can have the formof a microchip card, a module with PCMCIA or USB interface, or even atransmission module without contact.

The transaction programmes on Internet require an authentication by aX.509 type certificate. It has been established that part of thiscertificate can be common to a large number of users and represents thesection suitable for the authority (implicit) emitting suchcertificates.

It is thus advantageous, thanks to this invention, to store only thepart suitable for each user (explicit) in the removable support, in ourexample this security module is a microchip card. This avoids aredundancy of data thus better use of the memory.

In fact, in these modules, data storage having contractual type contentsis preferred such as the transactions carried out by the holder.

Although this certificate is fractionated, the signature of theissuing-authority on the ensemble of the authority sections and holderallows re-establishing the relation between these two entities.

Therefore if one of the two parts is modified, the unique image cannotbe identical to the value of the calculated authentication with thepublic key of the issuing authority on this signature.

By signature, one understands the process that consists in determining aunique image of the data considered by this signature (by a Hashfunction for example) and encrypting this unique image by the privatekey of the entity which signs. The algorithm used for the establishmentof this signature is an encryption of an asymmetrical type.

For verification of such a signature, one uses the public key of thisentity to decipher the received signature and this value is comparedwith the result of the unique image carried out on the data toauthenticate. If the deciphered value and the unique image are equal,the certificate is considered to be authentic and have data integrity.

The invention will be better understood thanks to the following detaileddescription, which refers to attached drawings, which are given as anon-limitative example, in which:

FIG. 1 represents the verification of the certificate of the issuingauthority,

FIG. 2 represents the configuration showing the two parts of thecertificate,

FIG. 3 represents the authentication of the reconstituted certificate,

FIG. 4 shows the processing method of a transaction,

FIG. 5 represents the authentication method of the time,

FIG. 6 shows the conclusion signature on the data set,

FIG. 7 shows the sent message.

FIG. 1 represents the extraction of the public key of the rootcertificate by the security module SM.

The root certificate RCA is the certificate of the issuing authority.This unit asks the STB host unit to send the RCA root certificateassociated with the holder's certificate TCI1. This root certificatecontains the public key CAPU of the issuing authority. This key allowsauthenticating the holder's reconstituted certificate with the implicitpart and the explicit part of the holder's certificate. The STB hostunit sends this root certificate to the security module SM to extractthe public key CAPU. At the time of the installation of the holder'scertificate in the security module, the latter conserves the image H5that is the result of the Hash function on the root certificate RCA.

Concurrent with the extraction of the public key CAPU (see module X) theHash function is carried out with the block B on the explicit andimplicit data of the root certificate (explicit=part of the issuingauthority, implicit =part of the authority having certified the issuingauthority) and the result H5′ is compared to the referred value H5initially stored. If the two values differ, the authenticationoperations are stopped and the host unit is informed.

When the two values H5 and H5′ are equal, the public key of the issuingauthority is safeguarded and can be used for authentication operationsof the holder's reconstituted certificate.

If the STB host unit does not dispose of the root certificate, it canmake the request on the Internet network near for example to a sitehaving a certificate directory (CDir) allowing access to desiredcertificates (CA1, CA2, CAn).

In FIG. 2, a first smart card SM1 is represented in which the explicitpart TCE1 of the holder as well as its secret key TS1 are stored. Withinthe STB host unit, is access software to Internet BR currently callednavigator.

With regard to the authentication functions, this programme has securitysoftware SA that carries out the interface with the smart card. It isalso able to transmit the certificate in its whole and because of this,contains the data of the authority section TCI1.

The STB host unit is linked to the rest of the world by Internet forexample to accede to the servers PS1, PS2, the sites to obtain the dataof the issuing authority CauD, information about the time TSAu and thedata about the root certificate directory CDir.

At the time of the transfer between the security module SM1 and the STBhost unit, the data relating to the holder section TCEI are sent to thehost unit according to a procedure starting at the security modulepreponderantly.

This operation will be described in more detail further on.

The verification of the integrity of this certificate is done with theprocess illustrated in FIG. 3. The multimedia unit or host unit,represented here with the STB block, transmits the data of thecertificate contained in the destination host unit of the securitymodule SM. For this purpose, if the “authority” part (implicit) iscontained in its whole in the STB host unit, it is possible to storepart of the “user” data (explicit) in the host unit too, the rest beingplaced in the security module SM.

Those data are organized in module A supplied on the one hand by the STBhost unit, and on the other hand by data TCE1 of the memory of thesecurity module. It is important to note here that the data TCE1 of thesecurity module are not simply sent to the STB host unit for treatmentbut that there is the security module SM which controls the operation.

The data reconstituted by module A, are redirected towards the STB hostunit and form the certificate CERT in view of being sent towards aservice provider. Module A operates as a synchroniser and reconstructsthe certificate according to the predefined format and disclosed by thecomposed block of elements TCE, TCI, SCAT.

In the certificate reconstituted in module A, one extracts the signatureSCAT from the holder's certificate coming from the STB host unit (seemodule X).

The gathered data, excluding the signature SCAT, are sent to module Bthat has the task of determining a unique image from the assembly ofthose data.

This image is obtained by a Hash function (unidirectional and withoutcollision) which is carried out on the data set in a precise order H=f(TCE1, TCI1). It is admitted that there does not exist any differentdata set, which gives the same result as this function. This image isproduced by a unidirectional function and without Hash type collision.The used algorithm can be of type SHA-1 or MD5 and this image expressesthe data set singularly.

The algorithm type to use is specified in the certificate. This image issafeguarded in module B1 for future use.

To verify if the two parts of the certificate are integral andauthentic, the security module SM extracts the signature SCAT of thecertificate and deciphers the latter in module C thanks to the publickey of the authority CAPU.

For this operation, one considers the parameters contained in thecertificate, which describe the kind of signature and the length of thekeys.

In module D, the reference value B1′ is calculated and compared to theunique image B1. If the two values correspond, the certificate isauthentic and can be used for future operations disclosed by module E.In negative, the smart card SM will refuse every transaction operationand will inform the STB host unit.

FIG. 4 shows the following operation, which consists in authorizing atransaction. If the previous test on the authentication of thecertificate is positive (see modules D and E of FIG. 3) the STB hostmodule can send the transaction signed to a server PS1, PS2.

A transaction Q can be filtered by module F of the security module SM,module that contains the acceptance rules. In fact, it is possible todetermine a maximal amount or to enumerate a list of the institutes,which are accepted by the holder of the security module SM. Theseconditions can include a date of validity limit of the holder'scertificate.

Once the transaction has successfully passed the filter of module F, itis presented at module B, which calculates a Hash function H2 on theassembly of the transaction Q. The result B2 is stored for subsequentuse. This value H2 is then signed by the private key TS1 of the holderto form the transaction signature SQTM. Module A2 assembles the data ofthe transaction Q and the signature of the transaction SQTM to send ittowards the STB host unit. According to a variant of the invention, itis possible to add, a validity limit of the transaction, which isschematised by the time TM to the transaction Q.

A way to determine this time is to use a time stamp T which can be thecurrent time and to add the validity duration ?T. So this time TM isrepresented by: TM=T+?T.

This validity limit TM is added to transaction Q at the time of thedetermination of the Hash function in module B and at the time of thedata set in module A2. When the transaction is received by the servicesupplier, it will verify that this limit is not passed.

According to a variant of the invention, the use of a validity limit TMcan be made obligatory if a certain transaction amount is reached.

In FIG. 5 the authentication operation of the time furnished by the STBhost unit is described. Those time data comprise the time T said, arandom part R and a signature on the two previous data. The time stamp Tas well as the random part R and the signature STA are transmitted tothe security module SM. Starting with the time stamp T, one determinesthe validity limit TM by adding the validity duration ?T. This limit isused to define a maximum duration during which a transaction can bemarked by this time.

The authentication is done in the same way as operations previouslydescribed, namely the calculation of a Hash function on the time stamp Tand the random R in module B after their assembly in module A.

The intermediate result H3 is stored in module B3 for subsequent use.

For determination of the value B3′ (module C) one uses the key TSPUwhich is the public key of the authority giving the time.

When the key TSPU is not available in security module SM, a request istransmitted via the STB host unit to research the certificate relatingto the issuing authority of the time T that contains this key.

One compares (module D) then this calculated value B3′ with the uniqueimage B3 of the data T and R, to determine if the time is authentic.

In FIG. 6 the assembly operation of the certificate and the transactionas indicated, and optionally the time as well as other data relating tothe transaction. The previous values B1 of the certificate, B2 of thetransaction and B3 of the time are organized in module A and sent tomodule B to determine the Hash function. This value is then signed bythe secret key of the holder TS1. The result is the signature SETM ofthe envelope the certificate assembly, transaction and time.

This envelope is shown in FIG. 7.

As the management of the memory is an important aspect in a securitymodule, the signature of the encasing SETM is determined on the base ofthe values resulting from the Hash functions of each step. This way ofproceeding allows linking all the data and guaranteeing that each partof the message has not been altered.

It would also be possible to calculate an encasing signature by takingeach element separately and calculating the Hash function on these.

Nevertheless this method involves the memorization of the entire messageto carry out this operation.

1-8. (canceled)
 9. Storage and exploitation method by a host unitconnected to a removable security module of an electronic certificate,said certificate having an authority section of the issuing authority, aholder section suitable for the holder of the certificate and asignature section determined by the issuing authority, wherein all orpart of the holder section is contained in the removable security moduleand in that at least the authority section is contained in the hostunit.
 10. Storage and exploitation method of an electronic certificateaccording to claim 9, having the following steps: transmitting theauthority section to the security module, reconstituting the certificatein the security module by assembling the holder section contained in thesecurity module, determining a unique image on the authority and holdersections, deciphering the signature thanks to the public key of theissuing authority of the certificate to obtain a referred sure value,comparing this referred value to the unique image of the authority andholder sections, informing the host unit if the two values diverge andstopping the exploitation.
 11. Method according to claim 10, wherein thesecurity module deals with the data of a transaction to authorizeaccording to the following steps: reception of a transaction request bythe security module, filtering this transaction according to filteringparameters by a filtering module, determination of a unique image of theaccepted transaction and calculation of a signature by the private keyof the holder, transmission of the data of the transaction and thesignature to the host unit.
 12. Method according to claim 11, wherein itconsists in adding to transaction a validity limit for determination ofthe unique image and the transaction signature and transmitting thisvalidity limit with the data of the transaction and the transactionsignature to the host unit.
 13. Method according to claim 9, wherein thesecurity module receives a time stamp and a random data which are signedby a certifying authority of the time and in that the security moduleauthenticates the integrity of this information and informs the hostunit if the exploitation can continue.
 14. Method according to claim 13,wherein the removable security module generates the validity limitstarting from the time stamp according to a duration of the securitymodule.
 15. Method according to claim 9, wherein the security moduledetermines a general signature thanks to its private key on the uniqueimages of the certificate of the transaction and of the temporary data.16. Method according to claim 10, wherein the security module determinesa general signature thanks to its private key on the unique images ofthe certificate of the transaction and of the temporary data.
 17. Methodaccording to claim 11, wherein the security module determines a generalsignature thanks to its private key on the unique images of thecertificate of the transaction and of the temporary data.
 18. Methodaccording to claim 9, wherein the removable security module is a smartcard.
 19. Method according to claim 10, wherein the removable securitymodule is a smart card.
 20. Method according to claim 11, wherein theremovable security module is a smart card.